


Git Workflow 


// FLATIRON SCHOOL 


Outline 


The need for a Git workflow 
Introducing branches 


Git feature branch workflow 

a. Walkthrough the creation of a 
branch 

b. Pull requests 

c. Merging branches 


Git fork workflow 


Git helps you manage work done on projects 





an 


But without a consistent git workflow, 
collaboration is easier said than done 





Without the agreement beforehand, 
collaboration feels like this 


GITIMERGE 





The team must all be in agreement on how the flow 
of changes will be applied from the beginning 





Git makes it easy to experiment with branches 


Buy cx rent on YouTube ( i) 





e They are named for a particular feature 
e Oncethat feature branch is successfully pulled into the master 
branch, it should be left alone or deleted 


Git feature branch workflow 
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Add other developers as collaborators to your main 
repository so they can push their changes to it on 
the main branch 
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descriptive_stats t 


Iknope/master 





Branches are a labeled series of commits towards 
building some feature (i.e. task) 





The default branch in git is called main 


Revisions # switches the repo to the main branch 
S git checkout main 


# pulls the latest commits from remote 
© $ git fetch origin 


Î | # merges the remote changes of main to 





the local copy to incorporate latest 
changes 
S git merge origin/main 


Commit 





main 


The name of a new branch takes both your username 


and the task you hope to accomplish 
eda 


| # checks out a branch called mbarry/eda based on main 
and the -b flag tells Git to create the branch if it doesn't 


already exist. 
© S git checkout -b mbarry/eda 








Update, add, commit, and push changes to your 
feature branch 


# pushes mbarry/eda to the central repository (origin), 
and the -u flag adds it as a remote tracking branch 
S git push -u origin mbarry/eda 





Aside from isolating feature development, branches 
make it possible to discuss changes via pull requests 


eda 








| | 


main Potential main 


give team member the opportunity to 
review the changes before they become a part of 
the main codebase 





Pull requests that do not follow team guidelines 
should be declined 





On the other hand, once are accepted, 
we are nearly done! 





© MarcusD. 


Once reviewed, pull requests are merged into the 


remote main branch 
eda 








local main remote main 


Reset your local copy of main to match the remote 
main 


| 


ff switches the repo to the main branch local main 
S git checkout main 
# pulls the latest commits from remote 


S git fetch origin 

ff resets the repo's local copy of main to match the latest 
version 

S git merge origin/main 





Now your local copy of main matches the 





knn 
All new branches are 
created from main for | 
future experiments 
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local main 


...but what happens when you have other branches? 
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Once main has been updated, you might want to 
merge its changes into another branch 





I EE 


docs local main 


Use? git merge «branch» to merge changes 
from one branch into another 





When do I merge branches? 


I should merge when: I don't need to merge when: 


An existing branch (e.g. docs) The feature branch does not rely 
needs the changes from another on any changes from another 
branch (e.g. main) branch 


Merge main into docs local main 
to add the changes from main 
into docs 

"e 











# switches the repo to the mbarry/docs branch Î 
S git checkout mbarry/docs 


# merge main branch into mbarry/docs branch dogs 
S git merge main 





By isolating features into separate branches, 
everybody can work independently and share 
changes with other developers 





Git fork workflow 


Fork Workflow 





Git fork workflow contains a project where you have 
one repository per collaborator 


| a JE 
rswanson/ma 





Provides a flexible way for large, organic teams (including 
untrusted third-parties) to collaborate securely 


O Why GitHub? Enterprise Explore Marketplace Pricing Sign in | Sign up | 





EJ python / cpython © Watch 1,066 Star 24,407 YFork 9,992 
Code Pull requests 1,012 Security hl Insights 
Ams Woah, this network is huge! We're showing only some of this network's repositories. x 


Contributors 


Commits * python / cpython 
X 1024537 / cpython 
Code frequency B 1st1/cpython 


Dependency graph ff 3inc / cpython 
2E 4kir4 / cpython 

Network $$ 550872569 / cpython 

m: 664956016 / cpython 

@ 80205 / cpython 

(3 a093130 / cpython 

ky a85758508 / cpython 

Tr aakanchhasinha / cpython 


Forks 


How this works between you and GitHub 


Developer 


Organization Git Repo 
(upstream) 


Another Developer Fork (anotherdev) 





How this differs from the feature branch workflow: 


Add other people's repositories in addition to other people's 
branches 


REMOTE REMOTE 





$ git remote add «name» «url» creates a 
new connection to another persons repository 


Your Kepe 


S git remote -v lists all remote connections associated in your repository 
S git branch -a shows both local and remote branches 

S git fetch <name> downloads objects from another repository 

5 git checkout -b «name of new branch» «repo name/branch 
name> will create a new branch from a particular branch in someone else's 


repository 


$ git merge <name>/<branch name» will merge someone else's branch 
from another repository into your currently checked out branch 


The team needs to decide what the git workflow 
looks like so everyone is aware when they need to 
update their local version of master 





